This invention relates to software program modules. More particularly, this invention relates to a method and system for injecting an exception into a program module to recover unsaved data.
Despite the best efforts of software developers, software programs inevitably fail at one time or another. One type of failure that a software program can encounter is a hang. A hang occurs when a program module is running and results in the suspension of the operation of the program module. Basically, a hang occurs when a program module is stuck in a loop of code that it cannot get out of for whatever reasons. Hangs are frustrating to users and, in some cases, may cause the user to lose work in the form of unsaved data.
In the past, users coped with hangs by spending hours on the phone with program support services personnel and/or rebooting the computer that was running the hung program module. The user""s decision to reboot usually occurred after the user tried, to no avail, to get the application program to respond to user input.
Furthermore, operating systems, such as Windows NT and Windows 95/98, provide users with a user interface for determining if an application is hung (not responding) or running. Through the user interface, a user is able to command the operating system to terminate a running or hung application program.
Although the above methods provide means for a user to bring an application program out of a hung state, they do not provide a solution for recovering unsaved data from a hung program module. Usually, unsaved data is lost, when the computer is rebooted or the program module is terminated through the operating system.
More closely related to the problem of recovering unsaved files from a hung application is the tool called DOTCRASH.exe (Dotcrash). Dotcrash is published by MSPress, available since 1999, and only operates with the Windows NT operating system. Dotcrash uses the Windows NT API CreateRemoteThread to induce an exception into a hung process. Further, Dotcrash may be used in conjunction with a Just-In-Time (JIT) debugger for the purpose of gathering crash dumps from a crash reporting executable. Crash dumps, while sometimes useful to software developers in debugging their programs, are not helpful to users in recovering unsaved data. Dotcrash is further unsuitable to the needs of unsaved data recovery as it fails to induce an exception on the main thread of the program. There are cases, such as OLE data objects, where the data recovery code must run on the thread that created the OLE data objects in order to recover as much of the unsaved data as possible.
Thus, there is a need to be able to induce an exception on the main thread of the hung application in order for that thread to execute special purpose data recovery code. There is a further need for a method and system for inducing any directed execution in a hung application on Windows 95/98 to provide capabilities for the purposes of data recovery parallel to those offered by CreateRemoteThread on Windows NT.
There is a further need for the induced crash to be intercepted, through the use of exception handling, so the user can be offered the opportunity to recover their unsaved data and initiate crash reporting.
The present invention satisfies the needs described above by providing a method and system for inducing an exception into a program module that is hung. In one embodiment, the present invention is a user-launched program module that allows a user to intentionally initiate an exception in a program module that is hung or not responding to the operating system. The user intentionally induces an exception into the program module to recover any data that was not saved prior to the hang. For the purpose of this discussion, an exception is a problem or change in running conditions that causes the operating system to crash or interrupt the hung program module.
The present invention comprises a program module, a hang manager program module, and an executable crash reporting program. A user, who believes that the program module is hung or not responding, can use the hang manager program module to inject an exception into the program module. At this time, the user may have the option of recovering unsaved data.
After the user commands the hang manager program module to inject the exception, the hang manager program module creates system kernel objects that are used to record the fact that the hang manager program module caused the crash. Then, in the case of Windows NT based O/S""s, the hang manager program module creates a second thread and initiates its execution in the program module, or, in the case of Windows 9x based O/S""s, the hang manager triggers the execution of a second thread that was created when the program module started up.
Next, this second thread instructs the operating system to stop executing the main thread in the program module. Once the main thread stops, the second thread determines the next instruction that the main thread would execute if active, and the memory address of that instruction. The second thread also saves the next instruction in a data block before changing the next instruction to an operating code that the processor defines as an illegal instruction. The next instruction is saved so that it later can be restored to the main thread. Finally, the second thread instructs the operating system to restart the main thread, thereby causing the main thread to execute the illegal instruction and create an exception in the program module.
In response to this exception, the operating system redirects the main thread to execute previously registered exception handling code within the program module. This exception handling code launches a crash reporting executable. The crash reporting executable checks for the existence of the kernel objects which the hang manager program module created, to determine if the exception was caused by the hang manager program module rather than an exception caused through normal execution which would be handled differently. The crash reporting executable will display a user interface to inform the user of the problem and to provide options specific to the program module. The user interface also includes an option to report the problem to a local or remote server. If the user chooses to report the problem that caused the hang, after the unsaved data is recovered, the crash reporting executable reports information regarding the nature of the hang to the local or remote server, which may prove useful to developers attempting to fix the problem.
If the user chose to recover unsaved data with the hang manager program module, the crash reporting executable will notify the program module to start its data recovery code. When the data recovery code has recovered the unsaved data, the data recovery code notifies the crash reporting executable that the recovery is complete. At this point, the crash reporting executable restarts the program module. The restarted program module displays to the user, through a user interface, the data that has been recovered with the data recovery code.
These and other features, advantages, and aspects of the present invention may be more clearly understood and appreciated from a review of the following detailed description of the disclosed embodiments and by reference to the appended drawings and claims.